1. Field of the Invention
This invention relates generally to computer networking, and more particularly to artifact downloads for interprocess services for use in client side applications.
2. Description of the Related Art
The art of networking computers has evolved over the years to bring computer users a rich communication and data sharing experience. To provide users with such a rich communication experience, standard communication protocols have been developed to improve interoperability between network applications. One such standard is the use of a stub and tie, or skeleton, for interprocess communication, particularly in distributed systems. This arrangement is often referred to as a Remote Procedure Call (RPC) mechanism.
In general, a distributed system is any system having multiple computers, which communicate over a network. Using the RPC paradigm, the processes that run on these computers each have an interface that is used by other processes on other machines to make requests. The interfaces are defined in an interface description language (IDL), where subroutine calls are defined in terms of the primitive data types, object references, and structures of these entities that are passed back and forth for the interface. These interfaces are then compiled, for any given implementation language, with the result being artifact files, such as stub and tie files. Once these are augmented with code provided by a human programmer, they can be compiled for the target operating system and processor.
The result is a stub/tie pair. The stub includes object code for the particular client processor and operating system that can accept a subroutine call from a client, translate the subroutine call into an interprocess protocol, and send the data bits across the physical connections of the network. The tie includes object code for the particular server processor and operating system that translates the bits received from the network into a data format that can be understood in the context of the receiver, makes a call to the server, and then translates any results into the interprocess protocol, which is sent back to the original client. Thereafter, the known bits received by the client stub are reformulated into a data format known by the client, and the call is finished.
For example, FIG. 1 is a diagram showing a conventional process for translating an IDL document into artifacts. As shown therein, the IDL document 100 delivers content to a compiler 110. As mentioned above, the IDL document 100 describes what a service application provides, in effect, acting as a manual. For example, based on this manual clients can determine how to use the services that are available from the application on a remote server. Based on the IDL document 100, the compiler 110 generates appropriate artifacts, which enable the use of the services described in the IDL document by a potential client. These artifacts can include, for example, stubs, skeletons, ties, data type definitions, exception definitions, and other data files that will be needed by the client application. For example, in FIG. 1, the compiler 110 generates a stub file 120 and a tie file 130.
FIG. 2 is a diagram representing a conventional RPC system for communication between a client and a server. A client application executing on a client system 210 makes a call using the stub 120. The stub 120 translates the call into an interprocess protocol and sends the data out across a communication channel 220, which can be, for example-, the Internet, a message queue, an inter process communication (IPC) in an operating system, email, socket, pipe, etc.
There is a decoupling in languages between the client and the server, for example one could be written in Java and the other written in Pearl. Therefore, the communication between the client and the server should be facilitated with artifacts, such as the stub 120 and the tie 130. Together, the artifacts act as translators, translating for example from Java to Pearl and then back from Pearl to Java.
The data from the call that was initiated by the client is received at tie 130, which translates the data into a call on the service application. The service application executing on the service server 240 performs the operation requested. Thereafter, the results of the operation are sent as a return to the tie 130, which packages the return data based on the interprocess protocol and sends the packaged return across the communication channel 220 to the stub 120. The stub 120 then provides the return to the client application.
Currently client application programmers need to create their own stub files and other related artifact files based on an IDL, generally through the use of a compiler. Since, compilers such as compiler 110 typically have multiple settings and options, artifacts generated by client application programmers can be generated incorrectly if the correct settings and options are not properly utilized. The requirement that application developers acquire these tools and the expertise required to operate these tools increases the difficulty of accessing services from a remote server.
In view of the foregoing, there is a need for a more direct and simplified method of communication between a client and a remote server across a network.